我不是Git专家，所以我经常在Git中学习会改变我对该工具看法的东西。 当显示git rebase -i ，我停止了对提交的思考。 当我发现git reflog ，我对重新部署变得更加自信。 但是我认为我被教过的最重要的命令之一是git rebase --onto 。

恕我直言，该文件在选择结果方面仍有改进的余地。 如果拍摄树的图像，它基本上会将树的一部分连根拔起，然后将其重新种植到其他位置。

让我们用以下树为例：

假设我们要将branch2从branch1移植到master：

这是一个很好的用例！ 在分支branch2 ，命令为git rebase --onto master branch1 。 这大约意味着将所有内容从branch2开始，从branch1移至master的尖端。 我通过记住第一个参数是新提交，第二个参数是旧提交来记住语法。

所以，但是有什么用例可以移动树的一部分呢？

虽然我要删除提交的第一个反射是git rebase -i ，但它并不总是最方便的。 它需要执行以下步骤：

如果要删除的提交是相邻的，则将rebase --onto更容易，因为您只需要新的和旧的提交，并且可以在一行中进行“删除”。

这是一个例子：

要删除最后3个提交X ， Y和Z ，您只需要：

拥有长期存在的分支通常是一个坏主意，但有时是必需的。

假设您需要将应用程序的一部分迁移到新框架，库等。 对于小型应用程序，可以由一个小型工作队来完成。 主要开发团队在周末结束时会指示您在周五离开之前提交所有内容。 当他们星期一回来时，一切都已迁移。

可悲的是，生活并不总是那么轻松，对于这样的理想情况，应用程序可能太大。 在这种情况下，工作队将与主要团队同时在专门的migration部门工作超过一个周末。 但是他们需要与main分支保持最新，并且仍然保持工作。

因此，他们不时地将migration分支重新设置在master的顶部：

这与合并不同，因为您使历史记录保持线性。

有时，出于多种原因，我想将更改保留在本地。 例如，我可能会修改代码质量工具的其他（或更严格的）规则。 在这种情况下，我想花时间评估这是否与整个团队相关。

如上所述，这是通过定期将我的本地tinker分支重新定为master 。

如上所述，它使我可以保持历史记录的线性，并根据需要更改与tinker相关的提交。 合并将阻止我执行此操作。

git rebase --onto可以有不同的用例。 最重要的问题与长期分支（无论是本地分支还是远程分支）的处理有关。

与往常一样，它只是工具带中的另一个工具，因此并非所有事物看起来都像钉子一样。

翻译自: https://blog.frankel.ch/multiple-usages-git-rebase-onto/